United States Patent and Trademark Office 



UNITED STATES DEPARTMENT OF COMMERCE 
United States Patent and Trademark Office 

Address. COMMISSIONER FOR PATENTS 
P.O. Box 1450 

Alexandria, Virginia 22313-1450 
www.uspto.gov 



APPLICATION NO. 


FILING DATE 


FIRST NAMED INVENTOR 


ATTORNEY DOCKET NO. 


CONFIRMATION NO. 


09/892,784 


06/27/2001 


Frank Bahren 


Westphal.6311 


9616 



7590 10/16/2007 

O'SHEA, GETZ & KOSAKOWSKI, P.C. 
1500 MAIN ST. 
SUITE 912 

SPRINGFIELD, MA 01 115 



EXAMINER 



CHANKONG, DOHM 



ART UNIT 



2152 



PAPER NUMBER 



MAIL DATE 



10/16/2007 



DELIVERY MODE 



PAPER 



Please find below and/or attached an Office communication concerning this application or proceeding. 

The time period for reply, if any, is set in the attached communication. 



PTOL-90A (Rev. 04/07) 



V«/#lflrv7 r~\\+l.t\JI§ wUf i I i 1 lOl y 


Application No. 

09/892,784 


Applicant(s) 

BAHREN ET AL. 


Examiner 

Dohm Chankong 


Art Unit 

2152 





The MAILING DATE of this communication appears on the cover sheet with the correspondence address - 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) OR THIRTY (30) DAYS, 

WHICHEVER IS LONGER, FROM THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 .136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 1 33). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1)S Responsive to communication(s) filed on 29 August 2007 . 
2a)D This action is FINAL. 2b)£3 This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 11, 453 O.G. 213. 

Disposition of Claims 

4) [X] Claim(s) 11,14-21 and 24-30 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) S Claim(s) 11, 14-21 and 24-30 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) D The specification is objected to by the Examiner. 

10) D The drawing(s) filed on is/are: a)D accepted or b)Q objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 
Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1 .121 (d). 

1 1) D The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 119 

12) D Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 119(a)-(d) or (f). 
a)D All b)Q Some * c)D None of: 

1 . □ Certified copies of the priority documents have been received. 

2. Q Certified copies of the priority documents have been received in Application No. . 

3. D Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attach ment(s) 

1) □ Notice of References Cited (PTO-892) 4) □ Interview Summary (PTO-413) 

2) □ Notice of Draftsperson's Patent Drawing Review (PTO-948) p ape r No(s)/Mail Date. . 

3) □ Information Disclosure Statement(s) (PTO/SB/08) 5 > □ Notice of Informal Patent Application 

Paper No(s)/Mail Date . 6) □ Other: . 



U.S. Patent and Trademark Office 
PTOL-326 (Rev. 08-06) 



Office Action Summary 



Part of Paper No./Mail Date 8 



Application/Control Number: 09/892,784 Page 2 

Art Unit: 2152 

DETAILED ACTION 

i> This action is in response to Applicant's request for continued examination, filed 
8.29.2007. Claims 11, 14-21, 24-27, 29, and 30 are amended. Claims n, 14-21 and 24-30 are 
presented for further examination. 

2> This is a non-final rejection. 

Response to Arguments 

I. THE siqi rejections OF CLAIMS 11 AND 21 ARE withdrawn. 

Applicant's amendment of claims 11 and 21 now recite a data telegram as part of a host 
network with hardware passing the telegram. As such, the §101 rejections have been overcome 
and are withdrawn. 

II. THE gio? REJECTION OF CLAIMS II, 14, 18 AND 20 UNDER THA ARE MAINTAINED. 
Applicant primarily argues that Jha fails to disclose a host network standard in 

conjunction with the SONET network [Applicant's arguments, pg. 16]. It is curious to note 
that while Applicant strongly emphasizes Jha's deficiency in disclosing a "host network" or a 
"host network standard", Applicant's specification is also entirely devoid of these terms. 
Applicant's specification neither explicitly defines or describes these terms. Applicant's 
argument, asserting that Jha's SONET network is not a host network, thus is premised 
entirely on undefined terminology. Without establishing what Applicant means by these 
terms, it is difficult to see how Applicant can argue that Jha fails to disclose them. 
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So without explicit description of these terms, the Office action can only infer their 
meaning by relying on inferences gleaned from Applicant's specification. For example, 
Applicant simply defines a standard as a protocol [Specification, pg. 2, J2 : "data telegrams 
which are formatted in accordance with standards or protocols"]. Applicant's claimed host 
network standard, which seemingly refers to the MOST standard, simply "defines the 
format for data telegrams by means of which data are transmitted in a multimedia system" 
which is designed in accordance with the host standard (here, the MOST standard) [Spec, 
Pg- 2, 5*]. 

Based on Applicant's own definition for a "standard", this Office action maintains 
that Applicant's Jha's SONET/HDT protocol meets the claimed limitation of a host 
network standard. Jha's entire invention is directed towards refashioning the old SONET 
protocol [column 3 «lines 46-47» : "current SONET protocols"] into a hybrid data transport 
protocol that can support multiple extraneous protocols within the SONET network 
[column 6 «lines 56-64»]. Like Applicant's MOST protocol, Jha's protocol defines the format 
for the SONET frames by means which data are transmitted in the SONET network 
[Figure 7]. 

And because Jha's protocol is used within a SONET network, Jha's SONET network 
is analogous to the claimed limitation of a host network. In response to this argument, 
Applicant claims that there is no teaching for "formatting of data" or "formatting of data 
according to the standards of ATM or IP"; Applicant further argues that there is no teaching 
of a "'format' for data in accordance with the SONET network" [Applicant's arguments, pg. 
16]. Jha's disclosure contradicts these claims. 
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Jha discloses a SONET payload envelope; the "format" of this envelope in accordance 
with Jha's SONET/HDT protocol [Figure 7 | column 7 «lines 39-6o» : describing the 
"format" of the SONET frame as containing a header as well as a SONET Path Over Head 
(POH) region]. Jha discloses data placed within this envelope that are in accordance with 
different extraneous protocols [Figure 7 : PPP, IP, Frame Relay data]. These components of 
the SONET frame, the header the POH region, the HDT headers [Fig. 9, 10] all suggest a 
frame that is formatted according to the protocol prescribed by the SONET network. 

Looking again to Applicant's specification, Applicant describes a data telegram that 
has a header section corresponding to the MOST protocol (or standard) and the remainder of 
the telegram corresponding to data formatted in accordance with the TCP/IP protocol. Jha's 
SONET/HDT frame discloses the same kind of formatting. 

Jha's frame contains a header that is formatted according to the SONET/HDT 
protocol [Figure 7 «item 202» | column 9 «lines 20-2i»]. In other words, this header portion is 
critical in order for the frame to be properly delivered within the SONET (host) network 
[column 7 «lines 4o-43» : "deterministic packet transport protocol"]. The remainder of the 
frame contains data formatted in accordance with protocols different from the HDT protocol 
[column 9 «lines 55'58»]. Thus, while the frame header is formatted according to the HDT 
protocol, the frame also contains data formatted according to extraneous protocols. This 
extra data must be placed in a specific section of the envelope and in accordance with the 
host protocol [Figure 7 «iterhs 204a-204e»]. 

Applicant's arguments for what is or is not a host network or host networking 
standard are not supported by Applicant's own specification. The interpretation of the 



Application/Control Number: 09/892,784 Page 5 

Art Unit: 2152 

claimed terms "host network" and "host networking standard" is consistent with Applicant's 
specification. Jha's use of a refashioned SONET/HDT protocol within the SONET network 
to deliver extraneous protocols such as TCP/IP reads on the claimed limitations as 
interpreted because the extraneous data must be placed within a correctly formatted frame 
(correct header and payload). There is nothing in Applicant's claim language or specification 
that distinguish the claimed host network or host networking standard over Jha's host 
protocol and host network. 

III. The sips rejection of claims 21, 24-26 and 28-30 under the MOST 

SPECIFICATION AND THA ARE ALSO MAINTAINED. 

As the Jha reference, Applicant repeats the same arguments that were addressed 
above. As to the MOST reference, Applicant argues that the cited portions, section 6, pgs. 32- 
35, do not disclose different data standards or protocols used in a MOST network. 

However, the MOST spec discloses throughout that the purpose of the MOST 
network is for its compatibility with devices that use different communications protocols 
[MOST spec -section 3.2.1, pg, 14 : "MOST devices can be anything from complex 
applications.. .video players and receivers, keypads" and "MOST devices shall provide a 
standard interface in terms of their.. .communications mechanism" | pg. 17 : "MOST system 
supports a variety of data types such as control data, packet data and synchronous stream data" J, 

The MOST spec further describes the purpose of the MOST frame as to be designed 
to provide "compatibility with a number of existing communication and data transport 
requirements" [section 6.6, pg. 33]. Finally, the MOST spec discloses that "[a] MOST 
network can be used in conjunction with a number of different protocols" and is "very 
flexible in terms of compatibility with a number of protocol layers" [section 9, pg. 42]. 
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Based on the MOST spec's stated desire to be compatible and flexible with different 
protocols and the different sections within the MOST frame for synchronous and 
asynchronous data, it is reasonable to infer that the MOST frame has different sections for . 
handling different "communication and data transport requirements." 

IV. Conclusion 

Based on the foregoing, Applicant's arguments are not found persuasive. The 
rejections set forth in the previous action are therefore maintained. 

Claim Rejections - 35 USC § 103 
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art 
are such that the subject matter as a whole would have been obvious at the time the invention was made to a 
person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 

3> Claims n, 14, 18 and 20 are rejected under 35 U.S.C § 103(a) as being unpatentable over 
Jha, U.S Patent No. 6.771.663. 

4> As to claim 11, Jha discloses a host network, comprising: 

a plurality of devices communicably coupled together, where the plurality of devices 
transmit and receive data telegrams within the host network [Figure 15], where the host 
network has a standard for the transmission of the data within the host network [Figure 7], 

where the data telegram comprises: 
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a data section having a pair of regions, one region in the pair of regions containing 
data formatted in a first instance in accordance with an extraneous standard that is different 
than the host network standard, the first region containing data formatted in a second 
instance in accordance with the host network standard [Figure 7 | Figure 9 «item 274» | 
column 5 «lines 52-5S» | column 7 «lines 39-6o» where: the host network utilizes a SONET 
protocol. Jha discloses that the SONET packet contains a SONET payload (first region) that 
contains data formatted in a variety of protocols (second region that is within the first 
region)]; and 

a header section that contains information specifying that the data within the first 
region of the data section are formatted in the first instance according to the extraneous 
standard and specifying that the data within the first region of the data section are formatted 
in the second instance according to the host network standard, where a second region in the 
pair of regions in the data section contains header information in the first instance associated 
with the extraneous standard specified by the information in the header section and in the 
second instance associated with the host network standard specified by the information in 
the header section, where a telegram identification portion of the header section that specifies 
an identification of data associated with the host network standard when the data in the first 
region of the data section is formatted in accordance with the host network standard in the 
second instance contains an identification of data associated with the extraneous standard in 
the first instance [Figure 7 «items 204a, 204b, 204c» | column 5 «line 67» to column 6 «line 5» 
I column 7 «lines 39-6o» | column 9 «lines 55-6o» | Figure 11 «item 302» | column 11 «lines 26- 
37»]. 
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Jha also discloses a telegram length portion of the header section that specifies a 
length of the data associated with the host network standard when the data in the first region 
of the data section is formatted in accordance with the host network standard in the second 
instance [column 7 «lines 6i-65» | column 10 «lines 27'30»] but does not expressly disclose 
that the portion no longer specifies the length of the data associated with the host network 
standard when the data in the first region of the data section is formatted in accordance with 
the. extraneous standard. 

However, this functionality is implied by Jha's disclosure. Jha discloses that the data 
in the data section of the telegram may be formatted in accordance with both host or 
extraneous standards [column 11 «lines 26-37»J. Thus, when the data is in accordance with 
the extraneous standard, the length portion specifies the length of the data of the extraneous 
standard and not the host standard. Therefore Jha implicitly discloses that the telegram 
length portion no longer specifies the length of the data associated with the host network 
standard when the data in the first region of the data section is formatted in accordance with 
the extraneous standard. 

5> As to claim 14, Jha discloses the data telegram of claim 11, where the data telegram is 
divided into frames, the frames into blocks, and the blocks into bytes [Figure 7 | column 8 
«lines 20-42»]. 



6> As to claim 18, Jha discloses the data telegram of claim 11, wherein the extraneous 
standard comprises Internet Protocol (IP) standard [column 7 «lines 46*49»]. 
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7> As to claim 20, Jha discloses the data telegram of claim 11, where the header section of 
the data telegram is formatted in accordance with the host network standard [column 7 
«lines 39-6o» where the host network is SONET (use of the payload envelope)]. 

8> Claims 15 and 16 are rejected under 35 U.S.C § 103(a) as being unpatentable over Jha, in 
view of the MOST Specification Framework Rev. 1.1 ["MOST spec"]. 

9> As to claim 15, Jha does disclose a header section with the information contained in 
the header [column 9 «lines 20*30»] and the information is contained in a predetermined 
location in the header section [Figure 7 «item 2o6»] but does not specifically disclose a data 
telegram where the host network comprises a MOST network, where the host network 
standard comprises a standard associated with the MOST network. 

io> The MOST spec discloses a data telegram wherein the first data transmission 
protocol is MOST and the host network standard is the MOST standard [section 2.1 | section 
3 section 6 ("MOST Frame Structure")]. It would have been obvious to one of ordinary 
skill in the art at the time the invention was made to implement the MOST protocol and 
standard in Jha's network to obtain MOST's advantages of increasing the speed of the 
network and decreasing cost of technology in automotive environments. Jha suggests this 
implementation as his network is fully compatible with current and future optical (fiber) 
networks [column 14 «lines i-23»]. 
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n> As to claim 16, Jha does disclose the host network in which data are transmitted by 
means of a telegram having a header section comprising a plurality of bytes [Figure 7 «items 
200, 202»] and where the information is contained in a predetermined one of the plurality of 
bytes of the header section but does not explicitly disclose a MOST network or a MOST 
telegram. 

I2> In an analogous art, the MOST spec discloses a data telegram wherein the network is 
a MOST network in which data are transmitted by means of MOST telegrams having a 
header [section 2.1 | section 4 | section 6 ("MOST Frame Structure")]* It would have been 
obvious to one of ordinary skill in the art at the time the invention was made to implement 
the Jha's ring network and frames as a MOST network and MOST telegrams respectively, 
to obtain MOST's advantages and functionality of increasing the speed of the network and 
decreasing cost of technology in automotive environments. 

I3> Claims 17 and 19 are rejected under 35 U.S.C § 103(a) as being unpatentable over Jha, in 
view of in view of Flanders et al, U.S Patent No, 6.172.980 ["Flanders"]. 

I4> As to claim 17, Jha discloses that his network is suited for transporting data of 
extraneous standards [column 14 «lines 24'3o»], but does not explicitly disclose that the 
extraneous standard comprises a Transmission Control Protocol (TCP) standard. 
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i$> Flanders teaches a data telegram wherein the extraneous standard is TCP [column 7 
<lines I2-I4>]. It would have been obvious to one of ordinary skill in the art to implement 
TCP as the extraneous standard for Jha's data telegram, as TCP is a ubiquitous standard in 
the network arts. 

i6> As to claim 19, Jha discloses that his network is suited for transporting data of 
extraneous standards and especially packets [column 14 «lines 24'30»], but does not explicitly 
disclose that the extraneous standard comprises an Internet Packet Exchange protocol (IPX) 
standard. 

iy> Flanders teaches a data telegram wherein the extraneous standard is IPX [column 6 
<lines 8-n>]. It would have been obvious to one of ordinary skill in the art to implement IPX 
as the extraneous standard for Jha's data telegram, as IPX is a ubiquitous standard in the 
network arts. 

i8> Claims 21, 24*26 and 28-30 are rejected under 35 U.S.C § 103(a) as being unpatentable 
over the MOST spec, in view of Jha. 

I9> As to claims 21 and 28, the MOST spec discloses a data telegram for transmitting data 
within a MOST network having a MOST standard that defines the transmission of data 
within the MOST network [sections 2.1 and 2.4], the data telegram comprising: 
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a data section containing data formatted in a first instance in accordance with an 
extraneous standard that is different than the MOST standard, the first region containing 
data formatted in a second instance in accordance with the MOST standard [section 2.5 | 
sections 5, 6.7, 6.8.(1-4) where : the MOST standard is compatible with a number of different 
protocols, the packets of which are transported to the various nodes using the MOST 
standard]. 

The MOST spec also discloses a header section having a plurality of bytes [section 5, 
page 31] but does not explicitly disclose that the header section has a predetermined region of 
which contains information specifying that the data section is formatted according to the 
extraneous standard, that the data section has a pair of regions, or the header section contains 
a telegram identification portion and a telegram length portion. 

20> Similar to Jha, MOST spec is directed towards transporting various data types within 
container structures [section 6.6, section 9 : "equipment such as multimedia computers, 
analog audio gateways, multimedia CD players, hi-fi audio equipment, telecommunication 
terminals.. .etc, can all be networked to interact"]. As such, one of ordinary skill in the art 
would realize the need for a means of identification of the data stored in the containers so the 
destination nodes are aware of the kind of data they are receiving. Jha discloses a network 
similar to MOST [a hybrid data transport over optical networks]. 

Specifically, Jha discloses a data section having a pair of regions, one region in the 
pair of regions containing the data, and the second region containing header information 
associated with the extraneous standard specified in the header section [Figure 7 | column 7 



Application/Control Number: 09/892,784 P a g e l 3 

Art Unit: 2152 

«lines 39'6o»]. Jha discloses a header section having a predetermined region that contains 
information specifying that the data within the first region of the data section are formatted 
in the first instance according to the extraneous standard and specifying that the data within 
the first region of the data section are formatted in the second instance according to the host 
standard [column 8 «lines 49-63»], where a second region in the pair of the regions in the 
data section contains header information in the first instance associated with the extraneous 
standard specified by the information in the header section and in the second instance 
associated with the MOST standard specified by the information in the header section 
[Figure 7 | column 7 «lines 46-49»]. 

Jha also discloses a telegram identification portion and a telegram length portion 
within the header section [see claim 11 rejection, above]. The purpose of these portions are to 
enable the system to make appropriate decisions on how to handle the data contained within 
the telegram by determining the protocols and length of the packet [see Jha, Figure 11 | Figure 

«]. 

Therefore, it would have been obvious to one of ordinary skill in the art to incorporate 
Jha's header functionality into MOST's header to enable identification of the multiple traffic 
types (standards) of the data payload. Further, it would have been obvious to incorporate 
Jha's data section with its pair of regions into MOST's data section to enable an increase in 
the data traffic capabilities of the MOST network. 



2i> 



As to claim 24, the MOST spec discloses the data telegram of claim 21, where the 
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information is contained in the header section [section 5 - page 31], but does not explicitly 
state that the it is contained in the last byte of the header section. 

22> Saito discloses a frame header that stores information of the kind of data in the 
last byte of the header section [column 1 «line 6o» to column 2 «line i»]. It would have been 
obvious to one of ordinary skill in the art to implement Flanders' header into the MOST 
header to obtain the advantage of having a fixed location for the protocol identifier in the 
header; this way, the network devices can quickly locate the protocol type of the data. 

23> As to claim 25, the MOST spec discloses the data telegram of claim 21, where the 
extraneous standard comprises a Transmission Control Protocol (TCP) standard [section 2.5 
- see "MOST 'Open* Model" figure]. 

24> As to claim 26, the MOST spec discloses the data telegram of claim 21, wherein the 
extraneous standard comprises an Internet Protocol (IP) standard [section 2.5, section 9 - see 
"MOST 'Open' Model" figure and "multimedia computers"]. 

25> As to claim 28, the MOST spec discloses a MOST multimedia system comprising: 
a plurality of multimedia devices communicably coupled through a communication 
path and defining a MOST network, where the MOST network includes a standard that 
defines transmission of data within the MOST network, and wherein the multimedia 
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devices transmit and receive data telegrams within the MOST network standard [sections 2.1 
and 2.4], 

wherein the data telegram comprises: 

a data section containing data formatted in accordance with a prescribable extraneous 
standard that is different than the MOST standard [section 2.5 | sections 5, 6.7, 6.8. (1-4)]. 

The MOST spec also discloses a header section having a plurality of bytes [section 5] 
but does not specifically disclose a header has a predetermined region that specifies that the 
data section is formatted according to the extraneous standard nor does he disclose a data 
section having a pair of regions, one region in the pair of regions for the data, and where a 
second region in the pair of regions in the data section containing header information 
associated with the extraneous standard. 
* 

z6> Similar to Jha, MOST spec is directed towards transporting various data types within 
container structures [section 6.6, section 9 : "equipment such as multimedia computers, 
analog audio gateways, multimedia CD players, hi-fi audio equipment, telecommunication 
terminals. ..etc, can all be networked to interact"]. As such, one of ordinary skill in the art 
would realize the need for a means of identification of the data stored in the containers so the 
destination nodes are aware of the kind of data they are receiving. Jha discloses a network 
similar to MOST [a hybrid data transport over optical networks], and specifically, a data 
section having a pair of regions, one region in the pair of regions containing the data, and the 
second region containing header information associated with the extraneous standard 
specified in the header section [Figure 7 | column 7 «lines 39 - 6o»], as well as a header section 
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having a predetermined region that contains information specifying that the data within the 
data section are formatted according to the extraneous standard [column 7 «lines 46-49»], 
Therefore, it would have been obvious to one of ordinary skill in the art to incorporate Jha's 
header functionality into MOST's header to enable identification of the multiple traffic 
types (standards) of the data payload. Further, it would have been obvious to incorporate 
Jha'a data section with its pair of regions into MOST's data section to enable an increase in 
the data traffic capabilities of the MOST network. 

27> As to claims 29 and 30, they do not teach or further define over the limitations recited 
in claims 24-26. Therefore, claims 29 and 30 are also rejected for the same reasons set forth in 
claims 24-26, supra . 

28> Claim 27 is rejected under 35 U.S.C § 103(a) as being unpatentable over MOST and 
Jha, in further view of Flanders. 

29> As to claim 27, the MOST spec discloses compatibility with a number of extraneous 
standards, including IP (see paragraph 32, section 9 : "telecommunication terminals")) but 
does not explicitly state that the extraneous standard is an Internet Packet Exchange (IPX) 
protocol standard. 

30 Flanders discloses IPX as an extraneous standard for a data telegram [column 6 <lines 
8-n>] where IPX and IP are compared to each other as routing protocols. Therefore, it would 
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have been obvious to one of ordinary skill in the art to have implemented IPX as an 
extraneous standard into the MOST spec as well in addition to IP, as they are both routing 
protocols, and would have obtained the further advantage of being compatible with IPX. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Dohm Chankong whose telephone number is 571.272.3942. 
The examiner can normally be reached on Monday-Friday [8:30 AM to 4:30 PM], 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Bunjob Jaroenchonwanit can be reached on 571.272.3913. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published 
applications may be obtained from either Private PAIR or Public PAIR. Status information 
for unpublished applications is available through Private PAIR only. For more information 
about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on 
access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217- 
9197 (toll-free). If you would like assistance from a USPTO Customer Service 
Representative or access to the automated information system, call 800-786-9199 (IN USA 
OR CANADA) or 571-272-1000. 
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